The present invention relates generally to service systems, and more particularly, to a method for request profiling in service systems with kernel events.
Increasing software complexity and higher user expectations on service quality present a difficult challenge in multi-tier application development. When an unexpected problem occurs, predicting internal states of all relevant components is nearly impossible. Retracing the history of execution flows is cumbersome and tricky, but often necessary in finding out the root cause of software problems. The overwhelming number of hardware and software combinations, different workload characteristics, and usage patterns of end users make such tasks even tougher. A mechanism that enables understanding system execution in a transparent manner, with minimal overhead, is invaluable.
One prior effort in the area of the invention is by B. C. Tak, C. Tang, C. Zhang, S. Govindan, B. Urgaonkar, and R. N. Chang. vpath: precise discovery of request processing paths from black-box observations of thread and network activities. In Proceedings of the 2009 conference on USENIX Annual technical conference, USENIX'09, pages 19-19, Berkeley, Calif., USA, 2009. USENIX Association, hereinafter vPath.
vPath, provides precise request processing path discovery for distributed applications by monitoring thread and communication activities of components of the distributed system. vPath can precisely match thread-TCP connection information, and operates at the virtual machine monitor (VMM) layer and hence it is agnostic to the application or the middleware platform used. vPath makes assumptions about the processing model of distributed system in the log processing phase, such as synchronous communication among components of the system and a single thread handling all the messages common to one request. This makes vPath ineffective for processing models such as event driven processing model where multiple requests are handled by one thread in interleaving fashion.
Referring to FIG. 6, there is shown a flow chart of vPath request path discovery process details. In block 701, vPATH monitors context switches, intercepts all the I/O related system calls and records the virtual machine (VM) ID, content of the CR3 register and the contents of the EBP register when such activity happens. In block 702, vPath precisely matches thread-TCP connection information using the information collected in 701. In block 703, vPath constructs end-to-end request paths by composing the event traces generated during the time of the TCP connections detected in 702 and by those processes using those TCP connections.
Another prior work is by P. Barham, A. Donnelly, R. Isaacs, and R. Mortier. Using magpie for request extraction and workload modelling. In Proceedings of the 6th conference on Symposium on Operating Systems Design & Implementation—Volume 6, pages 18-18, Berkeley, Calif., USA, 2004. USENIX Association, hereinafter Magpie. .Magpie uses low overhead system instrumentation to monitor fine-grained system activities at kernel, middleware and application levels. Magpie has a request extraction component which uses application level event schema to correlate traced events and then precisely capture the control flow and resource consumption of all requests. Magpie uses a combination of Event Tracing for Windows (ETW) system to capture kernel events WinPcap packet capture library to capture network packets and post ETW events Tracepoints put in the application to capture application/middleware specific events. By removing scheduling artifacts, whilst preserving causal dependencies, they obtain canonical request descriptions from which they can construct concise workload models suitable for performance prediction and change detection.
Still another prior work, by Hasan, et al., Method and apparatus for correlating events in a network. U.S. Pat. No. 7,631,222. Dec. 8, 2009, presents an invention of “Method and apparatus for correlating events in a network”. In Hasan et al. a uniquely configured data structure is used to store event information for each network entity, where logical and physical dependency relationships among entities are captured in the data structure. For each entity, the data structure is configured to store (a) a “genuine event set”, which includes a list of events that originated in association with the entity; and (b) a “derived event set”, which includes a list of records in which each record is associated with an event that originated in association with an entity that has a dependency relationship (e.g., layering or topological) with the entity. The derived event set may simply comprise references to the genuine event sets for entities that have a dependency relationship with the entity.
Accordingly, there is a need for request profiling in service systems with kernel events.